Hi @lukey78 !

Thanks for contributing to the project!

I have a few questions about this PR.

• There is a SIGNATURE_CHECKS env variable that defaults to 2, this will instruct freshclam to refresh signatures in an interval of the configured value's amount per day. So by default (2), it is checked every 12 hours. If you set this to 24, it will check every hour. At the very least, this setting and your proposal must match, so I would change your suggestion to 13h instead of 10h, otherwise the default behavior is that the pod is killed every 10 hours instead of seamlessly updating the signature database in the background.
• What is the purpose of killing the pod if a signature refresh fails and your new threshold is triggered? If consecutive starts also fails to load new signatures, the API will have the signature database from when the image was built (older than what it would have otherwise), and then restart again on the next threshold trigger. This is if there is a network error or something like that outside of the clamav-rest pod that is obstructing the signature refresh.
• I would also rather have a 5xx status code than 420, since this isn't a client error but a serverside error. Stating that, I don't have a suggestion for an existing status code candidate to use instead of 420.

Can you please elaborate in more detail what the practical purpose of this PR is? I might be missing something that you have discovered about this behavior.

Hi,

actually we use clamav-rest behind a nginx server forwarding requests to the service.
We want to monitor the virus scanner is properly working from the outside, therefore we also proxy the /healthcheck endpoint through our application to clamav-rest.

I agress that this might be not needed inside a cluster where dedicated liveness probes are used. This endpoint should also not be used to kill the container, just for monitoring.

Ensuring that updates are configured to be done twice a day does not mean the updates are always done. What if communicating with the update server fails? We might have several days without properly updated signatures and the health check should monitor this.

I agree with the default setting to match the SIGNATURE_CHECKS. But: A signature check does not mean that new sigantures are available. AFAIK ClamAV does not release new signatures to dedicated timestamps, or do they?

For the status code: I preferred a dedicated error because 5xx usually means something unexpected went wrong on the server side. Signatures that are not up-to-date are not a real error, but just a warning. Also, I want to differentiate between not up2date signatures and a non-running service.

See you,
Jens

That sounds reasonable. I will discuss with my co-maintainer and get back you!